home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000103_owner-urn-ietf _Thu Oct 24 15:53:07 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA18369 for urn-ietf-out; Thu, 24 Oct 1996 15:53:07 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA18364 for <urn-ietf@services.bunyip.com>; Thu, 24 Oct 1996 15:53:03 -0400
  3. From: jayhawk@ds.internic.net
  4. Received: from cagw2.att.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  5.         id AA29228  (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 15:52:53 -0400
  6. Received: from qsun.ho.att.com by caig2.att.att.com (SMI-8.6/EMS-1.2 sol2)
  7.     id PAA23207; Thu, 24 Oct 1996 15:55:09 -0400
  8. Received: from qsun2.ho.att.com.qsun2 by qsun.ho.att.com (4.1/EMS-1.1.1 SunOS)
  9.     id AA28010; Thu, 24 Oct 96 15:52:36 EDT
  10. Received: from sloop ([135.16.157.189]) by qsun2.ho.att.com.qsun2 (5.x/EMS-1.2 sol2)
  11.     id AA22485; Thu, 24 Oct 1996 15:51:31 -0400
  12. Message-Id: <9610241951.AA22485@qsun2.ho.att.com.qsun2>
  13. Original-From: "Ryan Moats" <jayhawk@ds.internic.net>
  14. To: "rdaniel@acl.lanl.gov" <rdaniel@acl.lanl.gov>,
  15.         "tallen@fsc.fujitsu.com" <tallen@fsc.fujitsu.com>,
  16.         "urn-ietf@bunyip.com" <urn-ietf@bunyip.com>
  17. Date: Thu, 24 Oct 96 14:57:28 
  18. Priority: Normal
  19. X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE
  20. Mime-Version: 1.0
  21. Content-Type: text/plain; charset="us-ascii"
  22. Content-Transfer-Encoding: 7bit
  23. Subject: Re: [URN] Unicode for NSS query
  24. Sender: owner-urn-ietf@services.bunyip.com
  25. Precedence: bulk
  26. Reply-To: jayhawk@ds.internic.net
  27. Errors-To: owner-urn-ietf@bunyip.com
  28.  
  29. On Thu, 24 Oct 1996 10:25:11 -0700 (PDT), Terry Allen wrote:
  30.  
  31. >| (Note that the NAPTR resolution scheme is probably going to find
  32. >| it impossible to get people to resolvers if that decision has to be made
  33. >| on non-ASCII characters in the URN. Since NAPTR is intended for
  34. >| Experimental rather than standards track this may be OK. I will take a
  35. >| look at what can be done to deal with UNICODE in regexps.)
  36. >
  37. >Ah, I see.  That part of the NSS that deals with its hierarchy
  38. >(and hence must be dealt with to get the client to a resolver)
  39. >presents a different problem than the rest of it; do I have that
  40. >right?  E.g.,
  41. >
  42. >  urn:world.dynasties:ottomans/15th.century/Bursa/XXXXXXXXXX
  43. >
  44. >has to get to the "Bursa" resolver, but XXXXXXXXXX could be 
  45. >anything?
  46.  
  47. I would have put this a different way.  My view of the NAPTR proposal is that the
  48. "resolver" is hit once the NID is looked up.  The 'regexp' stuff is how the resolver
  49. handles the NSS string.  Thus, what becomes impossible is not "getting to the resolver"
  50. in my view, it is either "extracting the naming authority" or "resolving the NSS".
  51.  
  52. Ryan Moats
  53.